1. Field of the Invention
Embodiments of the present invention generally relate to computer graphics and, more specifically, to a communication protocol and a client server system for the analysis and performance tuning of a graphics application executing on a remote device.
2. Description of the Related Art
The term rendering refers to a process performed by computer software and hardware in creating computer generated images that portray an object or scene. Typically, graphics hardware includes a graphics pipeline which is configured to generate successive frames by performing object geometry, vertex, and raster operations on a set of graphics primitives designated for each frame. The graphics pipeline is often highly configurable. For example, the graphics pipeline may be configured with different shader programs, lighting constants, and texture maps, among other things. A hardware driver provides an interface between a particular piece of graphics hardware and the calls provided by a graphics API. To create a frame, a graphics application invokes a “draw” call provided by the graphics API. Widely used graphics APIs include the OpenGL® API distributed by the Khronos group and the Direct3D® API distributed by Microsoft®.
A typical cycle for debugging the graphics application includes compiling and running the application. As the application is running, the developer looks for any anomalies or visual artifacts in frames rendered by the hardware and software. Visual artifacts may include elements of a frame that have an appearance other than what was intended by the developer, and non-visual anomalies includes poor performance of the graphics application, such as a low frame rendering rate. These issues may occur due to the application setting an incorrect render state, using a non-optimal or incorrect texture, or the use of incorrect parameters supplied to draw calls, among other things.
Application developers commonly perform simple experiments to diagnose and resolve these types of visual artifacts and performance issues. For example, the developer may experiment with the graphics application by tweaking program source code, adjusting a render state, or changing parameters of the graphics pipeline. The developer then runs the application to observe the result. Although this approach can be effective, it often becomes a cumbersome process. Further, when trying to diagnose and correct a problem on a certain target platforms such as an embedded or hand-held device (e.g., a hand-held video game console, a mobile phone, or convergence device), this process may be even more complicated as the graphics application must be deployed to the target device.
To address these issues resulting from a purely ad-hoc approach, graphical application debuggers are available. However, these applications typically execute on the same system as the graphics application. For graphics applications on handheld devices, however, this approach is, at best, impractical, due to the screen size of these devices. For example, most of the handheld video game devices currently available include a screen resolution of 320×240 or 640×480 pixels. Thus, the screen displays may be too small to provide developers with a useful debugging interface. Further, the hand-held device may not have the processing power (or multi-tasking capability) required to run a graphical application debugger alongside a graphical application.
As the foregoing illustrates, there remains a need in the art for a client server system for analysis and performance tuning of remote graphics devices.